Как вы знаете, в VMware vSphere (еще с версии 5.1) есть механизм репликации виртуальных машин vSphere Replication (VR), который позволяет создавать копию виртуальной машины на другом хосте и хранилище на случай сбоя. Именно она используется для асинхронной репликации в катастрофоустойчивом решении VMware vCenter Site Recovery Manager (SRM).

Периодичность репликации со стороны владельца системы должна задаваться политикой RPO (Recovery Point Objective), определяющей какое максимальное количество данных выраженное во времени мы можем потерять в случае сбоя. Например, RPO=15 минут означает, что самое большое, что не будет подлежать восстановлению - это изменения, произошедшие в системе за последние 15 минут.

Этот параметр и задается в первую очередь при настройке репликации для виртуальной машины:

Здесь можно задать значение от 15 минут до 24 часов. Однако не обязательно это требование будет выполнено, ведь если ширина канала у вас небольшая, а машин на хостах много, то они просто могут не поместиться в эту полосу с необходимой для обеспечения RPO частотой репликации.

Кстати, на данный момент расписание задачи репликации генерируется автоматически на основании исторических данных об изменении блоков виртуальных дисков за последние 48 часов. При этом расписание репликации пересчитывается каждый раз, когда виртуальная машина меняет свое состояние (питание, реконфигурация репликации и т.п.).

Поскольку задаче репликации нужно некоторое время на выполнение, каждая реплика считается устаревшей к тому времени, как сама задача считается выполненной. Поэтому чтобы предотвратить нарушение политики RPO, vSphere Replication должна выполнить задачу репликации за половину времени, определенного политикой RPO. Половину - так как если вторая репликация не сможет завершиться в случае сбоя, то мы сможем вернуться только в то состояние виртуальной машины, которое предшествовало началу первой репликации. Для этого потребуется восстановить первую реплику.

Ожидаемое время репликации вычисляется как среднее время последних 15 репликаций плюс 20% прибавка в качестве запаса к этому времени.

Рассмотрим пример:

Здесь у нас установлено RPO=60 минут. В первом случае на репликацию ушло 22 (текущая) и 23 (ожидаемая) минуты, каждая из них меньше половины времени RPO, соответственно политика считается выполненной. Во втором случае текущая и следующая репликации выходят за границы половины RPO, обе репликации в сумме дают 68 минут, поэтому политика считается нарушенной.

То есть, если исходный хост навернется через 67 минут, то мы сможем откатиться только в то состояние хоста, которое было 67 минут назад (восстановив первую реплику), что противоречит политике RPO, которая была определена как 60 минут.

В случае нарушения RPO сама репликация будет продолжена, однако вы будете получать вот такие алерты в консоли vSphere Client:

Что в этом случае делать? Выхода всего два - либо увеличивать и согласовывать новое RPO для сервиса виртуальной машины, либо увеличивать доступную полосу пропускания для сети репликации, что должно уменьшить время выполнения задачи.

Кстати, в плане определения необходимой ширины канала для репликации вам поможет специальное средство VMware vSphere Replication Capacity Planning Appliance.

На прошедшей неделе компания VMware вплотную занялась патчингом и фиксингом своих продуктов, закрывая те проблемные места, которые накопились за прошедшие пару-тройку месяцев. Прежде всего, было выпущено обновление ESXi550-201406401-SG, которое решает сразу две проблемы на VMware vSphere 5.5 Update 1.

Во-первых, мы уже писали о том, что  в VMware vSphere 5.5 Update 1 был баг - если использовать NFS-хранилища, то они периодически отваливаются, переходя в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

В выпущенном обновлении эта ошибка была исправлена.

Во-вторых, была также исправлена ошибка безопасности в OpenSSL, которая может оказаться даже серьезнее, чем исправленный ранее баг OpenSSL Heartbleed. В ESXi существует вероятность атаки типа MiM (Man in the Middle), о которой подробнее рассказано вот тут. Этот баг в приведенном выше обновлении был также зафикшен. Кстати, в своем блоге компания VMware объявила о том, что ее команда безопасности расследует новые возможные уязвимости OpenSSL, и вот тут приведены результаты ее работы.

Чтобы скачать патч, идем на VMware Patch Portal, выбираем там продукт "ESXi Embedded & Installable", версию релиза 5.5.0 и дату - 10 июня. Получаем ссылку на патч:

Применить этот патч можно и не скачивая его с сайта VMware, а просто с помощью следующей последовательности команд:

# открываем фаервол для http

esxcli network firewall ruleset set -e true -r httpClient

# устанавливаем образ ESXi-5.5.0-20140604001-standard из хранилища VMware Online depot

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.5.0-20140604001-standard

# перезагружаем хост ESXi

reboot

Также на днях компания VMware выпустила обновления продукта vCenter Server 5.5 Update 1b:

и vCloud Director 5.5.1.2:

Оба этих исправления прежде всего несут в себе фиксы в плане безопасности протокола OpenSSL, однако там есть и другие мелкие улучшения. Рекомендуется их установить.

Надо отметить, что VMware vCenter Server Appliance не подвержен багу OpenSSL, поэтому и исправлений для него нет.

Спустя полгода с момента выпуска прошлой версии основного руководства по обеспечению безопасности виртуальной инфраструктуры, компания VMware обновила версию этого документа до vSphere Hardening Guide 5.5 Update 1. Надо отметить, что руководство по безопасности вышло аж через 3 месяца после выпуска самой vSphere 5.5 Update 1, что как бы не очень хорошо, так как многие пользователи уже используют U1 в производственной среде, и руководство им пригодилось бы раньше. Ну да ладно, бывало нужно было ждать и дольше.

Доступен также лог изменений с момента прошлого документа:

В новой версии руководства есть следующие важные изменения:

• enable-VGA-Only-Mode - эта рекомендация должна быть применена для виртуальных серверов, которым не нужен графический режим (обычно он используется для VDI-инфраструктуры). То есть для веб-серверов, серверов Windows Core и т.п. нужно этот режим включить, чтобы уменьшить поверхность возможной атаки.
• disable-non-essential-3D-features - аналогично, отключаем 3D-графику для виртуальных машин, которым это не нужно.
• use-unique-roles - если у вас несколько сервисных аккаунтов, то им не нужно назначать одну роль на всех, а нужно создавать для каждого отдельную с необходимым набором привилегий для решения нужной задачи.
• change-sso-admin-password - это рекомендация сменить пароль для аккаунта administrator@vsphere.local, когда вы используете виртуальный модуль VMware vCSA (готовая ВМ с vCenter). Для обычного vCenter этот пароль просят сменить при установке. Удивительно, но этой рекомендации раньше не было.

Ну и кроме всего прочего, было пофикшены различные ошибки (например, значения в некоторых ячейках были обрезаны), а некоторые рекомендации переместились в другие категории.

На блогах, посвященных VMware vSphere, вышла интересная статья про то, как организовать именование и тэгирование объектов инфраструктуры виртуализации, чтобы в ней был порядок, и можно было бы просто найти нужную виртуальную машину, хранилище, сеть или другой объект. Попробуем здесь вкратце изложить основные моменты.

1. Стандарт именования объектов - ключ к порядку.

Здесь подход прост - виртуальные машины и прочие объекты должны именоваться согласно двум принципам:

• унифицированно (то есть по шаблону имени)
• чтобы было понятно, что там внутри находится

Как пример, для виртуальных машин можно использовать такую схему:

<назначение>_<тип окружения>_<порядковый номер>

Например:

EXCH_PROD_01

Датасторы можно именовать, например, так:

<датацентр>_<окружение>_<дисковый массив>_<порядковый номер>

Например:

SLC_STAGE_VPLEX_02

Для виртуальных сетей:

<имя>_<тип трафика>_<номер VLAN>

Например:

FIN_PCI_730

Ну и так далее. По аналогии назначаем шаблон именования и, собственно, имена для следующих объектов:

• Кластеры
• Шаблоны виртуальных машин
• Политики хранилищ
• Профили хостов
• И т.п.

Сделав это и применив к своей инфраструктуре, можно будет просто ориентироваться и находить нужные объекты, а также всегда помнить для чего они вообще нужны (частая проблема).

2. Переименование объектов, которые были созданы ранее.

Иногда политики именования объектов вводят уже после того, как в инфраструктуре полный бардак. Поэтому, зачастую, приходится переименовывать виртуальные машины. О том, как это делается, мы уже писали вот тут.

Если ваша лицензия позволяет делать Storage vMotion, то самый простой способ переименования - это:

• Переименовываем машину в VMware vSphere Web Client:

• Теперь видим, что между именем машины и именем папки на датасторе есть несоответствие:

• Делаем Storage vMotion машины на другое хранилище:

• После успешной миграции видим, что имя машины соответствует имени папки на хранилище (имя виртуального диска и остальных файлов в папке также станут корректными):

Кстати, есть специальный скрипт, который позволяет выявить все несоответствия между именами виртуальных машин и соответствующими папками на хранилищах.

3. Организация окружения с помощью тэгов.

Тэги позволяют ввести удобную категоризацию объектов виртуальной инфраструктуры по бизнес-критериям, что позволит ориентироваться в них с точки зрения понятных критериев (например, виртуальные машины какого-нибудь отдела), а также быстро находить то, что нужно.

Тэг назначается одному или нескольким объектам, после чего их можно искать в vSphere Web Client по этому тэгу.

Чтобы начать использовать тэги, переходим в соответствующий раздел в левом меню Web Client:

Создаем новую категорию, которая будет контейнером для тэгов. Выбираем сервер vCenter, имя категории, тип допустимых значений (один или несколько тэгов из категории на объект), а также типы объектов, которым можно назначать тэги из категории:

Теперь категория видна в представлении Tags > Category:

Далее создаем новый тэг, задав имя и привязав его к созданной категории:

Теперь этот тэг мы можем назначить указанным объектам, например, виртуальной машине:

Выбираем нужный тэг и назначаем его:

Теперь при наборе его в поиске он выскакивает как подсказка:

По тэгу мы сразу получаем доступ к нужным объектам в vSphere Web Client (например, все тестовые машины или все хранилища, используемые бухгалтерскими машинами):

Соблюдение этих простых правил позволит вам поддерживать чистоту и порядок в вашей виртуальной инфраструктуре.

Не так давно мы писали о грядущей новой версии продукта Veeam Backup and Replication v8, предназначенного для резервного копирования и репликации виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Напомним, что в восьмой версии продукта будет поддержка работы с массивами NetApp, а также было анонсировано средство для восстановления объектов каталога - Veeam Explorer for Active Directory.

Но пока новой версии нет, а администраторы VMware vSphere во всю уже начинают внедрять кластеры отказоустойчивости хранилищ VMware Virtual SAN. Специально для них компания Veeam уже сейчас выпустила обновление Veeam Backup & Replication 7.0 Patch 4, в котором технология VSAN полностью поддерживается (версия билда 7.0.0.871). Если раньше эти хранилища просто не показывались в списке объектов для резервного копирования, то теперь все они выводятся как датасторы:

Несмотря на то, что это всего лишь патч, в нем появилось множество новых возможностей:

• VMware Virtual SAN (VSAN) - в дополнение к базовой поддержке VSAN, которая есть и у других вендоров бэкапа, в решении Veeam учитывается специфика VSAN при работе механизма intelligent load-balancing. Это позволяет при резервном копировании использовать те прокси-сервера, которые будут выкачивать диски виртуальной машины, размещенные на том же хосте ESXi, что и прокси-сервер. Это позволяет максимально быстро проводить бэкап и не загружать дополнительно продуктивную сеть трафиком резервного копирования. Это очень полезная вещь, пример ее применения смотрите тут.
• Поддержка Microsoft SQL Server 2014 - теперь эта СУБД поддерживается не только как продакшен-нагрузка в резервируемой виртуальной машине, но и как бэкэнд база данных для сервера Veeam Backup and Replication, а также Enterprise Manager.
• License key auto update - теперь продукт будет автоматически обращаться к серверу лицензий Veeam, чтобы обновить ключи, если таковое необходимо. Это нововведение упрощает жизнь сервис-провайдерам, которые используют модель лицензирования на основе подписки (постоянно приходится продлять ключик).
• Backup Copy - максимальное число точек восстановления для задачи Backup Copy выросло до 999. Также эта задача поддерживает функцию "докачки" бэкапа при разрыве сетевого соединения.
• Hyper-V - добавлена поддержка нескольких Hardware VSS Providers, которые раньше не обнаруживались, а как следствие не могли использоваться при выполнении задачи РК. Также лучше стали создаваться снапшоты - теперь используется алгоритм ожидания окончания теневого копирования на томе вместо мгновенного завершения задачи.

По поводу поддержки VSAN есть интересный аспект работы при выборе прокси-серверов для резервного копирования. Если большая часть объектов хранилища машины размещена на одном хосте - то будет использоваться его бэкап-прокси, а вот если разница между объемом объектов менее 5% на двух хостах, то будут использованы оба прокси. Примеры:

• Host A = 70% хранения, Host B = 30 % , Host C = 0%, будет использован прокси только на Host A.
• Host A = 40% , Host B = 41% , Host C = 19%, будут использованы прокси на Host A и Host B одновременно.

Скачать обновление Veeam Backup & Replication 7.0 Patch 4 можно по этой ссылке.

Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.

При этом, например, в случае каких-нибудь сбоев в сети может произойти "разделение" кластеров на сегменты, что может повлечь неоднозначность в их поведении, поскольку они используют разные сети для поддержания кластера (хождения хартбитов).

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

• Какие хранилища нужно использовать в качестве datastore heartbeat?
• Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
• Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

• При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
• Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
• Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

Логика тут в принципе понятна, но в каждой конкретной ситуации может быть масса тонкостей касательно различных сценариев разделения и сбоев в сети, так что эти таблички лишь определяют направление мысли, а не дают готового рецепта.

В этом коротеньком посте приведем список горячих клавиш, которые помогут вам управляться с vSphere Web Client.

• Ctrl + Alt + 1 = Перейти в представление Home
• Ctrl + Alt + 2 = Перейти в представление vCenter Home
• Ctrl + Alt + 3 = Перейти в представление Hosts & Clusters
• Ctrl + Alt + 4 = Перейти в представление VM & Templates
• Ctrl + Alt + 5 = Перейти в представление Datastores
• Ctrl +Alt + 6 = Перейти в представление Networks
• Ctrl + Alt + S = Поместить фокус в поле поиска (Search)

Мы довольно часто пишем о "вложенной" виртуализации, которая позволяет запускать гипервизор VMware ESXi в виртуальной машине поверх ESXi, установленного уже на физическом сервере (nested virtualization). Для таких виртуальных ESXi есть даже свои VMware Tools. Однако, отметим сразу, что такое использование виртуализации официально не поддерживается со стороны VMware (в производственной среде), хотя и активно применяется в частном порядке ее сотрудниками, партнерами и заказчиками.

Так вот у многих администраторов есть закономерный вопрос - а надо ли лицензировать такие виртуальные ESXi? Ведь они все равно, кроме как для тестов, ни на что не годятся. Ответ прост - лицензировать надо. Об этом прямо написано в KB 2009916:

• VMware ESXi/ESX running in VMware Workstation or VMware Fusion
• VMware ESXi/ESX running in VMware ESXi/ESX
• VMware ESXi/ESX running in other third-party hypervisor solutions

Для тех, кто не хочет платить или хочет заплатить поменьше, есть 2 варианта:

• Постоянно переустанавливать ESXi в составе vSphere с триалом на 60 дней.
• Использовать бесплатный vSphere Hypervisor (он же Free ESXi) - но без vCenter.
• Использовать виртуальный ESXi, но с одним vCPU и, как следствие, платить только за одну лицензию. При этом можно поставить несколько виртуальных ядер на этот vCPU, и производительность будет почти та же, что и при нескольких процессорах. Как раз для этих целей VMware и был придуман параметр cpuid.coresPerSocket.

Одна из самых популярных статей на VM Guru - это статья про типы дисков виртуальных машин на платформе VMware vSphere. Там рассказано про все имеющиеся виды виртуальных дисков, среди которых можно выделить три основных:

• Lazy zeroed thick disks - все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Но при первом обращении ВМ к этому блоку он обнуляется.
• Eager zeroed thick disks - все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки.
• Thin disks ("тонкие диски") - эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски экономят пространство на массиве, так как не забивают его нулями и не требуют аллокации заданного объема.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

Специально для таких пользователей компания VMware провела тесты для последовательных и случайных операций при работе с виртуальными дисками различного типа, используя для этого дисковые массивы с SSD-накопителями.

Результаты оказались интересны - диски типа Thin и Lazy zeroed серьезно уступают в производительности дискам Eager zeroed, когда дело касается нагрузок случайного типа.

Использованная тестовая конфигурация:

• Сервер Dell R910 с 40 ядрами и 256 ГБ оперативной памяти.
• Дисковый массив Pure FA-420 FlashArray с двумя полками, на которых 44 флэш-диска по 238 ГБ каждый (суммарно 8.2 ТБ полезной емкости).
• Виртуальная машина Windows 2008 R2 Virtual Machine следующей конфигурации: 4 vCPU, 8 GB RAM, 40 GB OS/Boot Disk, 500 GB Data Disk.
• Инициатор SW iSCSI для карточки 10 Gb.

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Из таблицы видно, что все диски на последовательных нагрузках показывают примерно одинаковый результат, а вот на Random-нагрузках уже совершенно другая картина. Все это более наглядно можно увидеть графиков, где диски Thin и Lazy zeroed существенно проседают по производительности:

Вывод - не все йогурты одинаково полезны. Для высокопроизводительных нагрузок желательно использовать диски типа Eager zeroed - хуже точно не будет. Единственный их минус - требуется существенное время на их создание, поскольку происходит обнуление блоков. Но если ваш дисковый массив поддерживает примитивы VAAI, то много времени не понадобится: например, в том же тесте диск Eager zeroed размером 500 ГБ создался менее чем за одну минуту.

В выпущенной еще в прошлом году версии платформы виртуализации VMware vSphere 5.5 компания VMware представила решение App HA, которое выросло из функций  VM Monitoring, средствами которых можно было обнаруживать недоступность отдельной ВМ и перезапускать ее в случае сбоя. Потом эти возможности решили применить и к отдельным приложениям, в результате чего и появилось решение App HA:

Теперь App HA поддерживает некоторое количество приложений, поведением по "лечению" которых можно управлять на базе политик.

В середине апреля было выпущено решение VMware App HA 1.1, в котором появилось несколько новых возможностей:

• Теперь из коробки поддерживается больше приложений: Oracle (10g и 11g), а также PostgreSQL (8.x и 9.x).
• Поддержка любого сервиса: теперь агенты Hyperic можно использовать для любого сервиса в гостевой ОС (старт/стоп сервиса).
• Улучшенная совместимость с разными версиями vSphere - поддерживается как vSphere 5.5, так и 5.1.
• Возможность гибкого редактирования политик App HA, в том числе тех, которые уже назначены различным сервисам.
• Добавлено 6 языков, русского, к сожалению, нет.

Таким образом, решение App HA поддерживает мониторинг следующих приложений в гостевых ОС виртуальных машин:

А вот табличка совместимости App HA с различными компонентами VMware vSphere:

Полезные ссылки:

• Скачать App HA
• Документация
• Release notes
• Руководство по установке
• Гайд по совместимости

Мы уже много писали о решении VMware для создания кластеров хранилищ - технологии Virtual SAN, которая позволяет построить отказоустойчивую архитектуру хранения на базе локальных дисков серверов VMware ESXi.

На днях компания VMware выпустила очень полезный, а глвное бесплатный, онлайн-курс VMware Virtual SAN Fundamentals [V5.5], посвященный базовым принципам работы продукта и его администрирования.

Курс состоит из четырех модулей:

Module 1: Introduction to Virtual SAN

• Software-Defined Storage
• The Benefits of Virtual SAN
• Advantages of Virtual SAN over Traditional Storage and VSA.’

Module 2: Software-Defined Data Center

• Use Cases
• Virtual Desktop Infrastructure (VDI)
• Test and development
• Disaster recovery
• Management cluster storage
• DMZ
• Remote office/branch office
• POC Pre-Qualification Checklist

Module 3: Virtual SAN Architecture

• Virtual SAN Architecture
• Virtual SAN Objects and Components
• Virtual SAN prerequisites
• Virtual SAN cluster sizing requirements

Module 4: Configuring Virtual SAN (Optional)

• Enable Virtual SAN on a cluster
• Create disk group
• Storage policies
• Expand Virtual SAN cluster

Не так давно мы уже писали про приложение VMware vSphere Mobile Watchlist, которое позволяет мониторить виртуальную инфраструктуру с телефона на Android и iOS / iPhone, а также своевременно обнаруживать и решать проблемы удаленно. Недавно, 21 апреля, это приложение было обновлено - теперь новые версии (1.3) доступны для Android и iOS.

Новые возможности vSphere Mobile Watchlist:

• Добавлена поддержка хостов ESXi для мониторинга и решения проблем (раньше были только виртуальные машины).
• Улучшенное отображение связанных объектов (например, можно вывести все ВМ на хостах, хранящихся на определенном хранилище или в определенной ести), а также их алертов.
• Добавление хостов и виртуальных машин в список отслеживания напрямую из связанных объектов.
• Операции с набором хостов: включение/выключение, сетевые настройки и режим обслуживания (maintenance mode).
• Улучшенный интерфейс и система навигации по экранам.
• Несколько багофиксов.

Интересное обзорное видео продукта от Владана:

Пока возможности продукта слабоваты (например, нет vMotion и прочего), но сам факт того, что он развивается достаточно быстро (первая версия - в феврале), говорит о том, что скоро он будет вполне юзабелен.

Комьюнити по продукту доступно по этой ссылке. В качестве платформы поддерживается VMware vSphere 5 и более поздние версии.

Пару недель назад мы писали об уязвимости OpenSSL HeartBleed, которая коснулась виртуальной инфраструктуры VMware vSphere, а также других продуктов компании VMware. Напомним, что эта уязвимость позволяла злоумышленнику получить доступ к памяти сервера, где могут храниться логины/пароли и другая информация пользователей.

На прошлой неделе компания VMware выпустила фиксы для этого бага в виде обновлений VMware vSphere 5.5 Update 1a и VMware vSphere 5.5c, подробнее о которых написано в специальной статье KB 2076665.

Но тут, как часто бывает, вышла оказия. Нашелся еще один баг в VMware vSphere 5.5 Update 1 - оказывается, если для этого билда использовать NFS-хранилища, то они периодически отваливаются, то есть переходят в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

Решения для этой проблемы пока нет, поэтому рекомендуется просто откатиться на VMware vSphere 5.5 (без Update 1), если вы используете NFS-хранилища или модуль VSA.

Так вот, поэтому vSphere 5.5 Update 1 и просто vSphere 5.5 надо обновлять разными патчами для устранения уязвимости OpenSSL HeartBleed (чтобы на 5.5 не накатилась проблема с APD):

VMware ESXi 5.5, Patch Release ESXi550-201404001
Это патч только для фикса хостов ESXi 5.5 Update 1

VMware ESXi 5.5, Patch Release ESXi550-201404020
А этот патч для фикса хостов разных версий 5.5 за исключением ESXi 5.5 Update 1, а именно:
ESXi 5.5.0 hosts
ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile

Для серверов vCenter есть также соответствующие патчи:

• VMware vCenter Server 5.5 U1a
• VCVA 5.5 U1a
• VMware vCenter Server 5.5c
• VCVA 5.5c

VMware рекомендует сначала обновить серверы vCenter, а потом уже обновлять хосты ESXi. Сама процедура обновления описана в KB 2076692.

После обновления, на хостах ESXi надо перегенерить сертификаты и сменить пароли root. Делается это так:

cd /etc/vmware/ssl
/sbin/generate-certificates
chmod +t rui.crt
chmod +t rui.key
passwd root

Ну и надо отметить, что для всех остальных продуктов VMware также вышли фиксы уязвимости OpenSSL HeartBleed. Информация о них доступна по этой ссылке: http://www.vmware.com/security/advisories/VMSA-2014-0004.html.

Еще на прошлой неделе компания VMware выпустила познавательный документ "What’s New in VMware vSphere 5.5 Networking", в котором детально описываются нововведения, которые были сделаны в плане сетевого взаимодействия в VMware vSphere 5.5.

Напомним, что новая версия платформы принесла 5 основных нововведений в категории Networking:

• Улучшения Link Aggregation Control Protocol (LACP) - поддержка большего числа алгоритмов балансировки.
• Traffic Filtering - функции фильтрации трафика.
• Quality of Service Tagging - поддержка тэгирования различных типов трафика в соответствии с уровнем обслуживания, заданным для него на уровне VDS.
• Улучшения SR-IOV - напомним, что поддержка этих функций появилась еще в vSphere 5.1, теперь же процесс настройки этих функций существенно упрощен.
• Host-Level Packet Capture - появилась встроенная утилита для захвата пакетов на уровне хоста.

Собственно об этом всем подробно рассказывается в небольшом документе на 7 страницах, который содержит следующие разделы:

• VMware vSphere Distributed Switch Enhancements
  • Link Aggregation Control Protocol
  • Traffic Filtering
  • Quality of Service Tagging
• Troubleshooting and Performance Enhancements
  • Enhanced Host-Level Packet-Capture Tool
  • 40GB Network Adapter Support
  • Single-Root I/O Virtualization Enhancements

Скачать документ можно по этой ссылке.

Еще в октябре 2012 года компания Microsoft выпустила первую версию своей утилиты Virtual Machine Converter для преобразования виртуальных машин VMware в формат виртуальных дисков VHD на платформе Hyper-V. С тех пор прошло много времени, формат виртуальных дисков Microsoft обновился до VHDX, а платформа виртуализации Hyper-V обновилась до третьей версии.

Поэтому неделю назад Microsoft выпустила Virtual Machine Converter 2.0 (MVMC).

Новые возможности Virtual Machine Converter 2.0:

• Конверсия виртуальных дисков VMware в формат VHD с возможностью последующей загрузки на платформу Windows Azure.
• Нативная поддержка Windows PowerShell, что позволяет разрабатывать различные сценарии по автоматизации задач миграции на платформу Microsoft. На интерфейс PowerShell в MVMC 2.0 был заменен старый интерфейс командной строки MVMC 1.0.
• Поддержка конверсии виртуальных машин Linux с платформы VMware на хосты Hyper-V.
  
• Поддержка виртуальных машин, которые находятся в статусе "офлайн".
• Поддержка нового формата дисков VHDX при конверсии и миграции ВМ на платформы Windows Server 2012 R2 и Windows Server 2012 под управлением Hyper-V.
• Поддержка миграции ВМ на платформах VMware vSphere 5.5, VMware vSphere 5.1 и VMware vSphere 4.1 в среду Hyper-V.
• Поддержка гостевых ОС Windows Server 2012 R2, Windows Server 2012 и Windows 8, которые можно указывать как исходные при конверсии.

Механика работы утилиты Virtual Machine Converter проста - на платформе vSphere делается снапшот виртуальной машины, далее у нее удаляются VMware Tools, потом она выключается, ее диски преобразовываются и копируются на платформу Hyper-V, после чего происходит откат исходной виртуальной машины к начальному состоянию, которое было до снятия снапшота.

При конверсии офлайновой машины VMware Tools не удаляются, вместо этого отключаются сервисы и драйверы, связанные с VMware. Для гостевых ОС Linux удаления VMware Tools не происходит вовсе, поэтому делать это нужно вручную до конверсии.

Скачать Microsoft Virtual Machine Converter 2.0 вместе с документацией можно по этой ссылке.

В конце прошлой недели компания VMware сделала анонс долгожданного мажорного обновления своих продуктов для виртуализации ПК предприятия - VMware Horizon 6. С момента релиза VMware Horizon View 5.3 прошло всего 5 месяцев, а компания VMware вновь идет на штурм рынка VDI, делая очень серьезную заявку на победу над Citrix. Итак, давайте разбираться, что к чему.

На днях ИТ-сообщество переполошилось из-за очень неприятного факта - уязвимости OpenSSL HeartBleed, которая была обнаружена в версии защищенного протокола OpenSSL 1.0.1 и 1.0.2-beta. Уязвимость получилась из-за того, что отсутствует необходимая проверка границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

Это позволяет злоумышленнику получить доступ к оперативной памяти сервера, где хранятся, в том числе, сами секретные ключи, имена и пароли пользователей, а также много чего еще. После того, как нехороший товарищ получил, что хотел, обнаружить факт его проникновения в систему невозможно. За один такт можно получить сегмент в 64 КБ памяти, но делать это такими кусочками можно сколь угодно долго, постоянно обновляя соединение.

Как пишет Хабр, 1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали Heartbleed. То есть, пару лет любой желающий мог вылавливать данные из памяти где-то 2/3 всех защищенных серверов мира. Эта версия OpenSSL используется в веб-серверах Nginx и Apache, в почтовых серверах, IM-системах, VPN, а также еще очень-очень много где. Сертификаты скомпрометированы, логины/пароли, возможно, утекли к посторонним людям. Кошмар, бардак, ядерная война.

Например, уязвимость есть вот в этих Linux-дистрибутивах:

• Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
• CentOS 6.5, OpenSSL 1.0.1e-15)
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
• FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

Ну и, конечно же, серверы VMware ESXi 5.5 (build 1331820) и ESXi 5.5 Update 1 (build 1623387) также имеют эту уязвимость. Проверить это просто - выполняем команду:

# vmware -vl

VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA

# openssl version -a

OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Feb 26 16:34:26 PST 2013

Видим, что здесь версия 1.0.1e, которая подвержена уязвимости.

А вот для пользователей VMware ESXi 5.1 бонус - уязвимости тут нет, так как используется другой бранч OpenSSL (0.9.8y):

# vmware -vl

VMware ESXi 5.1.0 build-1612806
VMware ESXi 5.1.0 Update 2

# openssl version -a

OpenSSL 0.9.8y 5 Feb 2013
built on: Wed Mar 20 20:44:08 PDT 2013

Есть даже вот такая табличка с VMware Communities, где показано, какие компоненты и каких версий подвержены уязвимости (выделенные цветом - подвержены):

Фикса бага пока нет - но он ожидается в ближайшие дни (возможно, на момент прочтения вами этой заметки он уже выйдет). За развитием ситуации можно также следить тут.

Подробное описание уязвимости можно прочитать на специальном сайте: http://heartbleed.com/.

Проверить свой публичный сайт на наличие уязвимой версии протокола можно вот тут: http://filippo.io/Heartbleed/.

Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.

Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:

Действительно, в этом случае в логе FDM можно увидеть вот такую запись:

2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113

Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).

Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:

В этом случае в логе FDM мы обнаружим что-то вроде такого:

2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113

Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.

Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.

Недавно компания VMware начала серию статей про совместимость ее решения для организации кластеров хранилищ Virtual SAN с различными продуктами (например, с vCloud Automation Center и решением для резервного копирования vSphere Data Protection). Но многих пользователей интересует юзкейс использования VSAN для катастрофоустойчивой инфраструктуры, управляемой VMware Site Recovery Manager. А именно, с точки зрения экономии, наиболее интересным вариантом является создание резервной инфраструктуры на базе хранилищ локальных дисков серверов VMware ESXi, бэкэнд которых обеспечивается кластером хранилищ VSAN:

Такая схема полностью поддерживается со стороны VMware, как для решения vSphere Replication, обеспечивающего репликацию виртуальных машин на резервный сайт и его VSAN-хранилища, так и для vCenter Site Recovery Manager, обеспечивающего оркестрацию процесса.

Естественно, на данный момент поддерживается совместимость SRM+VSAN только на базе технологии асинхронной репликации vSphere Replication, поэтому такой сценарий не подойдет тем, кто хочет обеспечить RPO=0 для сервисов виртуальных машин в случае массового сбоя или катастрофы на основной площадке. Но для сценариев с RPO=15 минут такая схема вполне подойдет.

Зато такая схема не требует больших вложений в резервную инфраструктуру - не нужно покупать дорогостоящие FC-хранилища, SAN-коммутаторы и прочее. Для организации такой схемы резервирования можно использовать как только механизм vSphere Replication (но тогда потребуются регулярные ручные операции + ручное сопровождение в случае сбоя), так и автоматизировать процесс с помощью vCenter SRM.

При этом SRM может обеспечить следующие возможности:

• Автоматизированный Failover и Failback (нужно только нажать кнопку).
• Управление процессом восстановления из консоли vCenter.
• Возможность запланированной миграции сервисов на резервную площадку (при этом основную площадку можно сделать резервной).
• Несколько точек для восстановления в случае порчи данных (например, надо откатиться на день назад).
• Возможность протестировать процесс восстановления, не затрагивая продакшен-среду.

На тему всего этого компания VMware сделала отличное поясняющее видео, в котором показан процесс переезда с традиционной SAN-инфраструктуры на новую площадку, где хранилища построены на базе технологии VMware Virtual SAN:

Не все администраторы VMware vSphere знают о том, что в версии vSphere 5.5, компания VMware сделала специальную настройку для виртуальных машин - Latency Sensitivity. Она позволяет снизить издержки на виртуализацию для виртуальной машины в случае, когда требуется ее производительность близкая к нативной (то есть почти без потерь на нужды слоя виртуализации).

Найти ее можно в vSphere Web Client, если выбрать нужную ВМ, перейти на вкладку Manage, далее выбрать Settings->VM Options и в разделе Advanced Settings перейти на опцию Latency Sensitivity:

Там можно выбрать значения Low, High, Medium и Normal, однако значения Medium и Normal в vSphere 5.5 являются экспериментальными, поэтому пока можно использовать только Low (по умолчанию) и High (режим высокой производительности для чувствительных нагрузок).

Детально о том, что конкретно делает этот режим, можно почитать в документе "Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5", мы же здесь приведем основные моменты.

Итак, если вы ставите Latency Sensivity для виртуальной машины в значение High, происходит следующее:

Виртуальная машина получает эксклюзивный доступ к физическим ресурсам хоста

• Планировщик CPU хоста ESXi определяет возможность того, может ли быть предоставлен эксклюзивный доступ виртуального процессора vCPU к физическому процессору (ядру) сервера pCPU, учитывая реальное состояние процессора (нагруженность, over-commit и прочее). При возможности происходит резервирование pCPU для виртуального процессора на 100%. В этом случае никакие другие vCPU и трэды не могут быть исполнены на этом pCPU (включая VMkernel I/O threads).
• Возможность latency-sensitivity требует от пользователя установки резервирования памяти (Memory Reservation), чтобы выделенная виртуальной машине память не была ненароком отдана другой машине средствами Memory Ballooning. Это позволит дать гарантию, что машина всегда будет иметь в своем распоряжении четко выделенный сегмент физической оперативной памяти хоста ESXi, даже в случае недостатка ресурсов на хосте.

Обход слоя виртуализации

• Как только машина получила эксклюзивный доступ к pCPU, ее виртуальный процессор может напрямую взаимодействовать с его ресурсами в обход планировщика VMkernel. Это ликвидирует затраты на переключение между VMkernel и монитором виртуальных машин (VMM), однако переключения между исполнением кода гостевой ОС и VMM по-прежнему остаются (но это делается очень быстро за счет технологий аппаратной виртуализации, которые есть сейчас в любом процессоре).

Тюнинг механизмов виртуализации на хосте

• Когда в качестве виртуального сетевого адаптера (VMNIC) виртуальной машины используется устройство VMXNET3, то функция Interrupt coalescing и поддержка LRO отключаются, чтобы уменьшить время отклика и джиттер. Если виртуальной машине не нужны такие функции, как vMotion, NetIOC и Fault tolerance, то можно и нужно использовать механизмы проброса сетевого устройства напрямую в виртуальную машину (pass-through) через механизм Single-root I/O virtualization (SR-IOV). Поддержка этого механизма появилась еще в VMware vSphere 5.1, но была существенно доработана в версии 5.5.

Вкратце это все, но больше новых подробностей о требовательных ко времени отклика виртуальных машинах можно почерпнуть из приведенного выше документа.

Некоторые администраторы (которые, например, используют контроллер домена как единую точку руления инфрастуктурой) были удивлены, что с выходом VMware vSphere 5.5 толстый C#-клиент vSphere Client отказывается устанавливаться на контроллере Active Directory. При попытке такой установки будет показана ошибка:

vSphere Client requires Windows XP SP2 or later. 
vSphere Client cannot be installed on a Domain Controller.

Все это от того, что у Microsoft есть стандарт о том, что на контроллере домена не должно быть установлено никакого дополнительного ПО, не относящегося к функциям AD. И VMware вынуждена ему подчиняться. Хотя это и не логично - не всем нужна отдельная машина в небольшой инфраструктуре чисто под управление VMware vSphere.

Ограничение обходится просто. Запускаем установщик клиента с параметром обхода проверок:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Второй вариант - использовать на контроллере домена виртуализованный с помощью ThinApp толстый клиент (ThinApped vSphere Client), о котором мы уже писали тут.

Но его придется создать самостоятельно - актуальная версия поддерживаемой сейчас платформы - vSphere 5.0. Хотя есть кастомные версии и для 5.1.

Некоторым администраторам VMware vSphere в крупных инфраструктурах иногда приходится сталкиваться с задачей по переносу распределенного виртуального коммутатора VMware vSphere Distributed Switch в другую инфраструктуру (миграция, восстановление после сбоя и т.п.). При этом многие знают, как перенести vCenter и SSO, но не знают как быть с этим коммутатором.

Специально для этого компания VMware сделала обучающее видео по процессу резервного копирования и восстановления конфигурации VMware vSphere Distributed Switch:

Но это еще не все. Для тех, кто хочет пройти эти процессы самостоятельно на практике, VMware сделала пошаговое руководство в формате walkthrough (о них мы уже писали тут и тут) - то есть набора экранов, где нужно самостоятельно кликать на элементы в vSphere Web Client:

Как многие знают, в VMware vSphere 5.5 был полностью переписан движок сервисов аутентификации Single-Sign-On (SSO), так как раньше VMware использовала стороннее решение. Теперь же нет старой базы RSA, а контроллеры доменов Active Directory не нужно указывать напрямую. Механизм аутентификации стал проще, но при этом эффективнее.

Итак, например, у вас такая задача - есть домен, в который вы заводите серверы VMware ESXi и vCenter, и администраторы которого будут рулить виртуальной инфраструктурой. Но у вас есть и второй трастовый домен, пользователей которого вы бы также хотели наделять полномочиями по управлению своей частью инфраструктуры. Тут надо отметить, что полноценная поддержка односторонних и двусторонних AD-трастов появилась только в vSphere 5.5, поэтому в более ранних версиях платформы сделать этого по-нормальному не получится.

Итак, как мы помним, завести серверы VMware ESXi в домен AD можно в раздеде Configuration-> Authentication Services

Тут можно добавить основной домен, но в строчке Trusted Domain Controllers мы увидим пустоту, так как настраивать это нужно не через "толстый" vSphere Client, который скоро перестанет поддерживаться, а через "тонкий" vSphere Web Client, в котором возможности добавления источников аутентификации для сервера SSO весьма обширны.

Итак:

• Открываем Sphere Web Client по ссылке https://<адрес сервера vCenter>:9443/vsphere-client
• Заходим обязательно как administrator@vsphere.local. Именно под этим пользователем - обычный админ не прокатит - раздел SSO будет скрыт.
• Идем в раздел Administration > Single Sign-On > Configuration

Если этого раздела в vSphere Web Client вы не видите, значит вы зашли не под administrator@vsphere.local.

Далее идем в раздел Identity Sources и там нажимаем "+":

Добавляем новый источник:

Добавляем источник именно как "Active Directory as a LDAP Server", так как основной источник Active Directory (первый вариант) может быть добавлен только один.

Вот пример заполнения данных по домену:

Тут не заполнены только обязательные поля "Base DN for users" и "Base DN for groups". Если вы хотите искать пользователей во всем каталоге домена, то укажите в обоих этих полях просто подобное значение (из примера):

DC=virten,DC=local

Далее нужно протестировать соединение (Test Connection).

После того, как новый домен будет добавлен как Identity Source, его можно будет увидеть при добавлении любого разрешения на вкладке Permissions:

Вот так все и просто. Добавляете пользователя и даете ему права на различные объекты виртуальной инфраструктуры VMware vSphere.

В последнее время мы много писали о решении VMware Virtual SAN (например, тут, тут и тут), которое, казалось бы, нахваливали со всех сторон. Само по себе решение весьма неплохое, но в этом посте мы положим половничек дегтя в выглядящую распрекрасно бочку меда VSAN.

Итак, VMware Virtual SAN поставляется в трех вариантах:

• VMware VSAN с лицензией на процессоры хост-серверов VMware ESXi.
• VSAN with Data Protection - вместе с лицензией на средство резервного копирования VMware vSphere Data Protection.
• VSAN for Desktop - для размещения виртуальных ПК в инфраструктуре VMware Horizon View. Лицензируется на пользователя (именованного или по одновременным подключениям), вне зависимости от объема виртуальных ПК и используемых процессоров хостов.

Американская стоимость этих вариантов такова:

Как мы видим, если наш сервер VMware ESXi двухпроцессорный, то за лицензию VSAN на один сервер придется заплатить почти $5K. Что превышает стоимость некоторых неплохо упакованных серверов. Ах, да - мы забыли поддержку, которую обязательно приобретать с большинством продуктов VMware (без нее купить нельзя).

Давайте же взглянем на российский ценник:

• VMware Virtual SAN 5 for 1 processor (ST-VSAN-C) = $2 744,50
• Basic Support/Subscription for VMware Virtual SAN 5 for 1 processor (ST-VSAN-G-SSS-C) = $ 576,40 * 1,18 (НДС) = $680,15

Итого = $3424,65 * 2 (два процессора) = $6849,30

С учетом сегодняшнего курса доллара, который скачет как волшебный кролик, получается весьма (не)приличная сумма за программку для создания кластеров хранилищ.

Ну вы помните, да, что еще вообще-то нужно покупать VMware vSphere? Давайте взглянем, сколько сейчас стоит лицензия VMware vSphere Enterprise Plus на рассматриваемый нами сервер:

• VMware vSphere 5 Enterprise Plus for 1 processor (VS5-ENT-PL-C) = $4 543,50
• Basic Support/Subscription for VMware vSphere 5 Enterprise Plus for 1 processor for 1 year (VS5-ENT-PL-G-SSS-C) = $954,20 * 1,18 (НДС) = $1125,95

Итак, стоимость VMware vSphere на 1 сервер составляет: $5669,45 * 2 (два процессора) = $11 338,90.

Ну что ж, мы близки к катарсису. Сложим стоимость лицензий VMware vSphere и Virtual SAN для одного двухпроцессорного сервера:

$6849,30 + $11 338,90 = $ 18 188,20

Восемнадцать штук баксов за софт на сервере! Может это и нормально, кто знает. Этот пост не о том, как это дорого, а о том, во сколько это вам обойдется. Так-то.

Ну и для тех, кто готов идти дальше несмотря ни на что, обновились демки решения Virtual SAN на сайте проекта VMware Product Walkthrough Demos:

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...

Давно что-то не было новостей в сфере обновления инструментов для автоматизации операций в инфраструктуре VMware vSphere. Но вот они и пришли - сразу же после выхода VMware vSphere 5.5 и технологии Virtua SAN компания VMware выпустила обновление PowerCLI 5.5 R2.

Напомним, что PowerCLI является надстройкой над Microsoft PowerShell, которая позволяет администраторам просто управлять компонентами виртуальной инфраструктуры через командлеты:

Эта версия PowerCLI действительно принесла много нового, а именно:

• Возможность управления решением vCenter Site Recovery Manager через публичный API.
• Возможность создания/удаления тэгов и категорий тэгов.
• Получение статуса и настройка режима Enhanced vMotion Compatibility (EVC) для кластеров.
• Управление политиками безопасности для обычных виртуальных коммутаторов (vSwitch) и их групп портов.
• Поддержка Windows PowerShell 4.0.
• Поддержка серверов vSphere с настроенным IPv6.
• Указание приоритета миграции ВМ (VMotionPriority для командлета Move-VM).
• Возможность использования объекта Hard Disk как RelatedObject в методе Get-Datastore.
• Командлет Get-Datastore позволяет фильтровать вывод по кластерам.
• Командлеты Get-Stat и Get-StatType теперь работают со всеми типами, что позволяет собирать больше статистической информации.
• Добавлена поддержка сетевых адаптеров e1000e.
• Возможность указания всех значений в параметре DiskStorageFormat при клонировании виртуальной машины.
• Поддержка 64-битных ОС для методов New-OSCustomizationSpec и Set-OSCustomizationSpec.
• Свойство ToolsVersion объекта VMGuest показывает версию тулзов как строку.
• Возможность использования объекта virtual portgroup как RelatedObject в методах Get-VirtualSwitch и Get-DVSwitch.
• Получение списка ВМ рассортированного по виртуальным коммутаторам.
• Различные исправления ошибок и улучшения производительности командлетов, которые можно посмотреть в логе изменений.

Вот какие штуки теперь можно использовать для решения VMware SRM через PowerCLI:

• Protect a Virtual Machine - настройка репликации ВМ на удаленную площадку.
  
• Connect-SrmServer - соединение с сервером vCenter Site Recovery Manager (SRM).
• Create a Report of the Virtual Machines Associated with All Protection Groups - простенький отчет о виртуальных машинах и протекш-группах, в которые они входят.
• Create a Report of the Protected Virtual Machines - простенький отчет о всех защищенных SRM виртуальных машинах.

Кроме vSphere PowerCLI 5.5 R2 обновился также и vCloud Director PowerCLI R2, который можно опционально установить при развертывании этого средства.

Больше информации о новых возможностях интерфейса PowerCLI можно получить из документа "VMware vSphere PowerCLI 5.5 Release 2 User’s Guide". А о самих командлетах можно почитать в документе "VMware vSphere PowerCLI 5.5 Release 2 Cmdlet Reference".

Скачать PowerCLI 5.5 R2 можно бесплатно по этой ссылке.

Недавно мы писали о том, что компания VMware планирует выпуск решения для создания кластеров хранилищ на базе локальных дисков серверов - VMware Virtual SAN. И вот это случилось - вышла первая версия VMware Virtual SAN 1.0 и обновление VMware vSphere 5.5 Update 1, в котором есть поддержка VSAN (кстати, апгрейд с бета-версий VSAN на релизную не поддерживается). Для ESXi и vCenter апдейт с прошлой версии является кумулятивным, поэтому нет нужды накатывать предыдущие патчи для 5.5.

Помимо поддержки VMware VSAN, в платформе VMware vSphere 5.5 Update 1 добавились следующие функции:

• Плагин клиента vCloud Hybrid Service теперь доступен в vSphere Web Client.
• vCenter Server теперь полностью поддерживается на платформе Windows Server 2012 R2.
• Множественные исправления ошибок.

Надо отметить, что для поддержки VMware Virtual SAN обновилась не только платформа VMware vSphere, но и решение для виртуализации настольных ПК VMware Horizon View, которое теперь поддерживает размещение десктопов на хранилищах VSAN. Поэтому приведем ниже основные ссылки на обновившиеся компоненты:

• vCenter Server Update 1 download (+ release notes)
• ESXi 5.5 Update 1 download (+ release notes)
• Horizon View 5.3.1 download (VSAN release) (+ release notes)
• Horizon Workspace 1.8 (+ release notes)

Кстати, для тех, кто хочет узнать о том, как начать использовать VSAN с VMware Horizon View, есть вот такая KB 2073795.

В составе vSphere обновились также следующие компоненты до новых версий:

• vSphere Replication 5.5.1 (скачать)
• vSphere Data Protection 5.5.6 (скачать)
• VMware vCenter Orchestrator appliance 5.5.1 (скачать)

Но это еще не все. Обновились также и другие продукты VMware, чтобы обеспечить поддержку VSAN:

• VMware vCloud Director 5.5.1 (скачать)
• VMware vCenter Operations Manager Advanced 5.8.1 (скачать)
• VMware vCenter Hyperic 5.8.1 Server (и agent) (скачать)
• VMware vCenter Site recovery manager 5.5.1 (скачать)
• VMware vCloud Application Director 6.0.1 (скачать)

Централизованно все обновленные компоненты решений VMware можно найти по этой ссылке.

А вот в какой последовательности стоит обновлять эти компоненты, если у вас много продуктов VMware, и вы хотите внедрять VSAN:

* Если вы используете Cisco Nexus 1000V, см. KB 2057795
** Если вы используете vSphere Storage Appliance, убедитесь, что vCenter Server был обновлен минимум до версии vSphere 5.1 Update 1, чтобы он поддерживал vSphere Storage Appliance 5.5.

Напомним также все наши посты о решении VMware Virtual SAN:

• 10 марта выходит VMware Virtual SAN (VSAN) - основные особенности
• Калькулятор для расчета необходимой дисковой емкости под кластер VMware Virtual SAN (VSAN)
• Как кластер VMware Virtual SAN (VSAN) обслуживает запросы на чтение блоков
• Как ведет себя кластер VMware Virtual SAN (VSAN) в случае сбоев дисков или хоста VMware vSphere / ESXi
• Сайзинг кластеров хранилищ VMware VSAN в VMware vSphere и их отказоустойчивость
• Обновление VMware Virtual SAN Beta - и сравнение производительности с каким-то Flash-массивом
• Производительность кластера хранилищ VMware VSAN для виртуальных ПК VMware View при масштабировании
• Новый документ: "What’s New in VMware Virtual SAN (VSAN)"
• Чем отличаются VMware VSA и VSAN - сравнение

Ну и последнее, но не менее важное. Практически одновременно с релизом VSAN 1.0 компания VMware выпустила очень полезный документ "VMware VSAN Design and Sizing Guide", в котором приводятся различные рекомендации по построению инфраструктуры VSAN, а также выбору числа дисков, памяти и других параметров и количества хост-серверов VMware ESXi.

Также в документе приведены практические примеры по расчету необходимого числа хостов и дисковой емкости:

Документация по VMware VSAN доступна тут.

10 марта компания VMware выпустила важное обновление своей политики, касающейся сертификации VMware Certified Professional (VCP), о которой мы немало писали.

Теперь, согласно новым правилам, если специалист в течение двух лет с момента своей последней сертификации не сдал экзамен на квалификацию VCP по последней версии продуктов VMware, то эта сертификация не является действующей. Данная политика уже является вступившей в силу, но есть небольшая поблажка для тех, кто сертифицировался до 10 марта 2013 года - у них есть время до 10 марта 2015 года на ресертификацию. Остальные могут прибавить к дате своей сертификации +2 года, этот срок и будет тем, до которого нужно сдать еще один экзамен.

Во-первых, это влечет за собой отсутствие возможности подтверждения сертификации со стороны VMware, во-вторых, не позволяет использовать логотип на сайтах и в резюме, а, в-третьих (что самое важное), влияет на условия партнерства, которые предполагают наличие определенного количества сертифицированных специалистов VCP у партнера.

В принципе, этот шаг является весьма логичным, так как до этого времени у звания VMware VCP не было срока давности, а у других вендоров есть свои политики устаревания собственных сертификаций (зачастую, не очень понятные, как, например, у Citrix). Единственно, что два года - это маловато, можно было бы вполне сделать и три (как, например, у Microsoft).

Более подробно о новых изменениях в политике, касающейся сертификации VCP, можно почитать вот в этом FAQ.

Мы постоянно рассказываем о новых стенсилах, иконках, шаблонах и диаграммах, которые позволяют вам документировать виртуальную инфраструктуру, когда вы создаете презентации и различные схемы (например, тут, тут и тут). На днях компания Veeam Software обновила свои бесплатные стенсилы для Visio, которые теперь доступны в двух вариантах - 3D и 2D.

Стенсилы 2D-формата выполнены в стиле Windows Metro и позволяют создавать схемы в простом "плоском" стиле:

Среди шаблонов Veeam вы сможете найти следующие объекты виртуальной инфраструктуры как VMware, так и Microsoft:

• Хосты ESXi и Hyper-V
• Виртуальные датацентры
• Серверы SC VMM
• Локальные и общие хранилища
• Логические тома LUN
• Виртуальные машины (в различных состояниях)
• Сетевые адаптеры (NICs)
• Виртуальные сети и многое другое

Скачать бесплатные стенсилы Veeam для VMware и Microsoft можно по этой ссылке.

Мы уже очень много писали про технологию VMware VSAN, которая позволяет создать кластер из локальных хранилищ хостов VMware ESXi (например, последнее - тут, тут и тут). На днях стало известно, что 10 марта состоится релиз этого решения, которое будет поставляться как дополнение к VMware vSphere, либо как предустановленное решение на брендовых серверах.

VSAN - один из самых серьезных и сложных продуктов VMware. В его тестировании приняло участие более 12 тысяч пользователей, и вот версия 1.0 уже почти готова.

Какие особенности будут у финальной версии VMware Virtual SAN:

• Технологию Virtua SAN будет поддерживать новый релиз платформы виртуализации vSphere 5.5 Update 1, который, очевидно, будет выпущен вместе с VSAN. Также будет поддерживаться и решение VMware Horizon View.
• Апгрейд бета-версий VSAN на релизную версию поддерживаться не будет.
• Стоимость и комплектация изданий будут известны вместе с выходом продукта 10 марта.
• Обещают, что производительность кластера VSAN будет масштабироваться линейно по мере роста количества узлов в нем.
• В кластере хранилищ VSAN поддерживается до 32-х узлов. Минимально нужно 3 хоста ESXi.
• На одном узле поддерживается работа до 100 виртуальных машин. Всего, таким образом, получается до 3200 машин в кластере.
• Для работы кластера на каждом узле должны быть как SSD-диски (как минимум один), так и HDD-накопители. Если чего-то из этого нет - работать не будет.
• Максимально на одном узле поддерживается до 35 HDD-дисков и до 5 SSD-дисков (один SSD на 7 HDD, то есть каждые 7 дисков обязательно требуют твердотельный диск емкостью около 0.1 от совокупной емкости этих HDD).
• Суммарно поддерживаемая емкость кластера = 35 дисков * 32 хоста = 4.4 петабайта хранилища.
• Где можно использовать VSAN (например): для VDI-инфраструктуры, среднекритичные нагрузки (Tier 2/3) и DR-сценарии (хранилища резервной площадки).
• Минимальная скорость адаптера на хосте ESXi - 1 Гбит, но чтобы все работало надежно, очень рекомендуется строить сеть на адаптерах 10 Гбит. А все потому, что репликация идет синхронно.
• Дедупликации пока не будет.
• Производители оборудования, такие как Dell, HP и Cisco будут поддерживать VSAN и серверы "VSAN Ready". Вот тут можно посмотреть на список совместимого с VSAN оборудования. В день релиза станут доступными аж 13 готовых к VSAN конфигураций.
• Ввод-вывод на узле кластера разгоняли до 2-х миллионов IOPS (IOmeter 100% read, 4KB block size, а также 640K IOPS с профилем нагрузки 70/30 read/write и 4KB block size).
• Многие видели, что поддерживается совместная работа технологии VSAN с некоторыми решениями VMware, такими как vSphere Replication. Теперь также будет поддерживаться vSphere Data Protection for backups, vMotion, DRS, HA и многое другое.

Ну что ж, ждем с нетерпением выхода этой штуки, которая может оказаться весьма полезной многим.